CD ROM Paradise Collection 4/CD ROM Paradise Collection 4 1995 Nov.iso/program/hmcv14_1.zip/_ABOUT

Text File | 1995-01-09 | 15KB | 306 lines

0. Introduction to HM-Card
============================

HM-Card is a PC authoring system for hypermedia applications, and
is based on a novel method of hyper-linking. The editing and linking
facilities allow the creation of conventional hypermedia documents,
links and tours of various complexity. HM-Card will automatically
maintain the integrity of all hyper-links created. The hypermedia
databases created with HM-Card can then be integrated into other
systems or browsed separately using a stand-alone viewer.
The process of creation in HM-Card does not require any special
programming knowledge on the author's part. Animations or
complex question and answer analysis algorithms can be created
without resorting to traditional programming.
Although the terminology used in this manual may be familiar, a
basic understanding of HM-Data Model (the underlying concept of
HM-Card) is assumed. See Chapter 03 HM-Data Model  for more
information.

HM-Card runs under MicroSoft Windows version 3.1.

1. HM-Card Basics

Information native to HM-Card is stored internally in the form of a
database. By using a secure form of database, HM-Card keeps track
of information and maintains the integrity of links from section to
section.
There are three main components of HM-Card presentations: Media
Objects, Pages and Collections. Individual media objects are grouped
in pages of information. Pages can then organised in various ways as
collections.

2. Pages and Media Objects

Blocks of information displayed by HM-Card are referred to as
pages. A page is basically a linear list of various types of multimedia
information, called media objects. When a page is called upon to
present its information, it will access each media object more-or-less
sequentially. An object may not actually involve a visual display, but
some other form of media, such as a sound.
Objects which have a visual component are built up in layers on the
screen, obscuring images behind them. Non-visual objects have no
effect on screen graphics. An analysis object, in conjunction with a
branch objects allows the flow of object presentation to jump around,
repeating or skipping sections of objects. In this way a complex
interaction can be provided within a particular page.

3. HM-Data Model

Databases in HM-Card are made up of Structured Collections
(S-collections or just collections for short). Every S-collection
(instance) has a unique identifier, a name used by other S-collections
for addressing, and generally an associated page which will be called
content henceforth.  An S-collection encapsulates a particular
internal structure. The internal structure is a set of pages and/or other
S-collections (called members henceforth) related by a number of
computer-navigable links. One of the members of the S-collection
must be designated as head of the S-collection. Note that we connect
S-collections and pages. Note also that links are encapsulated within
a particular S-collection: they may only be defined between
members of the same S-collection. In this sense, links belong to a
particular S-collection; they do not belong to the hypermedia
database or to either of the members related by the link, hence the
"local referential integrity"  of the  model.
The HM Data Model provides a number of predefined subclasses of
S-collection. Simply speaking, subclasses of S-collection define a
particular topology of encapsulated links. For the purposes of this
paper, it suffices to describe the five predefined subclasses:
Envelope, Folder, Menu, and Freelinks:

1.Envelope: all members of an envelope are fully related,
every member is linked to every other member.

2.Folder: an ordered set of members, each member
having links to "next" and "previous" members.

3.Menu: a simple hierarchical structure; the head of a menu
S-collection includes links to all other members, and each
member is provided with a link to the head.

4.Freelinks: members of a freelinks S-collection may be
arbitrarily connected by means of special INSERT_LINK and
REMOVE_LINK operations.

Four important issues must be understood:

1.Conceptually, an S-collection X can be a member of n>1
other S-collections Y1 ,Y2, . . . , Yn. This does not mean
that X has to be physically stored n times; whether some
clever pointer mechanism or other technique is used instead
is part of the implementation and of no concern to the user.
In this important sense the HM Data Model offers a higher
level of abstraction than models involving arbitrary links: in
analogy to programming languages where abstract data
types offer a higher level of abstraction than data structures
based on explicit pointers.

2.Not only simple S-collections but also complex S-
collections can be members of more than one S-collection.
In this manner, larger "chunks" of information (including
their particular encapsulated navigational strategies) can be
reused in various parts of a hypermedia database.

3.S-collections need not be "stratified". An S-collection may
well consist of some simple S-collections, some slots, and
some complex S-collections.

4.Recursive membership is both possible and meaningful.


3.1 Navigational Operations

There are several things that a collection can do, of which the access
function is the most used. When a collection is accessed it presents
its content, the page associated with it.  By wrapping pages with
successive complex collections, the structure of a multimedia
presentation is created.
Thus, Navigation within the HM Data Model is accomplished via
three operations ACCESS, ZOOM_IN, and ZOOM_OUT , which are
addressed to a particular S-collection.
All S-collections can respond to the message ACCESS. It implies
executing the S-collection┤s content (i.e., presenting some text,
picture, audio, video clips etc.). Complex S-collections without
content forward the message to their head.
Link following within the HM Data Model is simply a form of
message passing. At any particular moment in time, the user can
navigate only through a single, specific S-collection called the
current container. Only members of the current container can
receive messages during navigation. Links within the current
container serve as a message passing paradigm. A concrete member
of the current container is the current member for each particular
navigational step. More precisely, the member that  most recently
received the message ACCESS is the current member.  Only members
related (linked) to the current member can be accessed (can receive
the message ACCESS) in the next step of navigation.
Since links are encapsulated within an S-collection, they become
available for navigation only when the S-collection has been
"entered" by means of the ZOOM_IN operation, which is available for
all complex S-collections. The ZOOM_IN message is automatically
addressed to the current member. After a ZOOM_IN operation, the
head of the new current container automatically becomes the current
member and is visualised appropriately (i.e. receives message
ACCESS).
The ZOOM_OUT operation  is the complement of ZOOM_IN.
ZOOM_OUT restores the current container and  current member to the
state they had before the most recent ZOOM_IN. Extending the
functionality of ZOOM_OUT to give access to any S-collection of
which the current collection is a member  is provided by the
operation ZOOM_UP. Together, ZOOM_IN, ZOOM_UP and ZOOM_OUT
provide users with the capability of navigating in a direction
orthogonal to the conventional plane of link-based browsing. Thus,
we say that the HM Data Model supports an additional dimension of
browsing hypermedia databases.
The three operations ACCESS, ZOOM_IN, ZOOM_UP and ZOOM_OUT
constitute the navigational element of an S-collection┤s public
interface. Navigation in our model leads to the activation of part of
the public interface, not directly to information content (i.e.
primitive nodes or anchors) as in many other models. In fact, this
object-orientation eases many of the problems associated with the
visualisation and aggregation of composites.

3.2 Operations for Modifying the Database

New S-collection instances are created with the operation CREATE,
whereby the name, content, and head are given as parameters. Once
an S-collection has been created, new members can be inserted and
existing members removed by means of the operations
INSERT_MEMBER and REMOVE_MEMBER. All links within S-
collections belonging to the classes Menu, Envelope, and Folder are
maintained automatically in accordance with their associated regular
structure.
Of course, the regularly structured subclasses do not restrict us from
using S-collections having arbitrarily connected members. Users can
create an S-collection of class Freelinks and explicitly define its link
structure using the messages INSERT_LINK and REMOVE_LINK.
At any point, an S-collection can be deleted with the DELETE
operation. In this case, its content and all links encapsulated within it
cease to exist. If a deleted S-collection has been reused (defined as a
member) by other S-collections it is removed from  S-collections by
means of the REMOVE_MEMBER operation.

4. The Editor, Linker and Executor

Three different programs make up the HM-Card authoring package.
The are the Editor, Linker and Viewer.
The Editor is used to create and edit the media objects contained in a
page. These pages are the base, upon which complex collections are
built. All objects native to HM-Card are available for editing and the
author is provided with powerful facilities for incorporating materials
already existing in electronic form (text files, graphic images, sound,
etc.) into presentations.

Following is a brief description of the 16 types of media objects
available.

Vector Graphics: These consist of common graphical elements such
as lines, rectangle, curves, splines, etc.

Text: These can be loaded into HM-Card in two ways, by typing the
information in directly, or by importing it from an existing text file.

Message and Mailbox: A message object is used to display variable
information, such as that stored in a mailbox. A mailbox can
remember states or information. This information can then be used to
control the flow of page execution.

Import: This object is a powerful aspect of HM-Card. It allows many
types of media to be loaded and displayed, from simple textual
information, to complex information from any OLE (Object Linking
and Embedding) compatible application.

Group: By importing a section of an existing page as a group,
complex graphics or animation objects can be re-used in other pages.

Pause and Branch: These objects control the flow of object display in
a page. They allow the flow to be halted temporarily, or diverted to a
different section of objects.

Beep and Flash: To attract or alert the user these object supply visual
or audio warnings.

Input and Analysis: The input object is used for input from the user
in the form of text or as a selection of options. This input can then be
analysed in a complex fashion and results used to control page
execution.

Snapshot: This object allows the a portion of the page to be captured,
saved and restored at a later date.

Fill: Complimenting the vector graphic objects, this objects will fill
an enclosed area with colour.

Animation: Any visible object or group can be animated in timed
sequences involving arbitrary trajectories.

Navigational objects: basic navigational operations of the HM-Data Model
(i.e. "Next", "Prior", "Zoom_IN" and "Zoom_Out" can be incorporated
into information pages in the form of objects.

The Linker is used to create and link complex collections. It allows all
collections to be linked together to form a hypermedia presentation
and it will maintain the integrity of all links created.

Various attributes of collections may be set and altered with this program.

Thus, such attributes define a particular type of link visualization.
The system supports the following types of link visualization
 (i.e. types of anchors).
- Link visualization in the form of scrollable list.
- Link visualization in the form of pushbuttons.
- Link visualization in the form of clickable areas ("hot" areas).
- Link visualization in the form of "hot"-words.

Additional attributes of an S-collection can install special regimes for
the S-collection:
"Automatic Zoom In", "Automatic Zoom Out", "Permanent Presence of a
Predefined Layout" and "Form Filling".

The regime of "Automatic Zoom In" means that when a member of the
S-collection is accessed in some way, the operation "Zoom In"
is carried out automatically.

In analogy, the regime "Automatic Zoom Out" means that when the head
of such S-collection is accessed in a way different from "initial
opening" of the S-collection, the operation "Zoom Out" is carried out
automatically. For instance, an S-collection of type "Folder" is closed
automatically after visualization of a "last" member.

The predefined Layout is a particular information page which is visualized
as a first part of the screen layout during browsing of the current
container. For instance, if a particular S-collection (say, S-collection
"A") is defined as a member of two different S-collections-containers
(say, as a member of "B" and "C" having different predefined layouts),
then visualization of the S-collection "A" depends on a particular
context (i.e. it is visualized differently as a member of "B" and as
a member of "C").
In analogy, some information common to all members of a particular
S-collection (say, a "help" message) can be defined once as such a
predefined layout.

Form is a named combination of attributes which are attached to every
member and/or head of an S-collection.
When a certain member (or head) is visualized on the screen, a form
defined for the S-collection (container) is also visualized as a part
of the screen layout. Fields attached to members of the S-collection are
filled by the user when a particular member is inserted into the
S-collection. Attributes attached to the head are dynamically calculated.
When members are inserted into an S-collection defined with this attribute,
the system demands filling predefined fields with particular values.

The Viewer is an independent program used to view presentations
previously created using the Editor and Linker.
The user can alter many aspects of the presentation they are
viewing. Thus, key-word search/modification, annotations and macro (tour)
recording and playback facility are available.

===========================================================
This is a very short, textual introduction to HM-Card.
More detailed documentation is available from the same FTP site
as a file called "hmcv14_2.zip"
Do not hesitate to contact the product supporters:
Email: [e-mail]